During the development of computerized systems (e.g. aircraft avionics), software development, integration, and test activities often do not occur until physical hardware is available. Various approaches have been attempted to perform these activities earlier in the timeline of product development from requirement definition to production. A first approach is to develop and test the software on a proxy system (e.g., a personal computer) and then port the software to the actual physical hardware when the hardware is eventually available. For example, in earliest stage of software development, Computer Software Units (CSU) can be developed and tested at the unit test level. CSUs can then be combined to build Computer Software Components (CSC). CSCs can be subsequently combined to create Computer Software Configuration Items (CSCI). At the CSCI level, there is enough software may be present to start integration level testing.
Integration testing with the first approach may provide an application program interface (API) that enables the software to execute on the proxy system. This API provides an abstraction layer allowing hardware of the proxy system to be used by the application program. In this approach, the virtual system is self-contained on the personal computer. Input/output calls by an API call to access a communications channel (e.g., a MIL-STD-1553 bus) would, for example, be routed to a simulated bus that connects the application software under development to other subsystem models on the bus for integration testing. However, to allow development of the application program on different types of proxy systems, the details of the actual hardware are abstracted differently. As a result, at least two different APIs are implemented for the application program—one for the proxy system, and one for the physical hardware. Accordingly, the application program is compiled for two different environments during development.
In a second approach, integration testing can be started before defining an API. This approach may be used with pure simulation techniques, such as Model Based Design (MBD) and Model Based System Engineering (MBSE). MBD provides early integration of core functionality of the application program. However, MBD and MBSE typically integrate only the core functionality of an application for a physical hardware device, while excluding large sections of application supporting software that exist in physical hardware, such as APIs, hand code, interrupt service routine's (ISRs), board support packages (BSPs), operating systems (OSs), and input output (I/O) protocols. MBD/MBSE can integrate with other simulations and this is sometimes called co-simulation, but MBD/MBSE is rarely concerned with how the actual transmission of data occurs between systems comprising an overall system.
A third approach to integration testing combines the application program with other systems without defining an API and without being concerned with how information is actually transferred in the system. This third approach modifies or patches application program to tie engineering units (e.g., variables having a value and a unit of measurement) directly with other simulated systems to integrate the overall system. Doing so is similar to the MBD/MBSE approach. However, this third approach works at the actual software level and not at the model level. However, it is difficult to script the connectivity modifications to the application program and the modifications/patches are often a time consuming manual process. Thus, the third approach is not well suited for early system design during which the application software frequently changes. The present disclosure is provided to address these and other problems.